Many companies and other organizations operate computer networks that interconnect numerous computing systems to support their operations, such as with the computing systems being co-located (e.g., as part of a local network) or instead located in multiple distinct geographical locations (e.g., connected via one or more private or public intermediate networks). For example, data centers housing significant numbers of interconnected computing systems have become commonplace, such as private data centers that are operated by and on behalf of a single organization, and public data centers that are operated by entities as businesses to provide computing resources to customers.
A few providers allow their customers to create logically isolated networks using resources located at such data centers. For example, a customer may be assigned some set of virtualized servers and/or other resources implemented at hosts managed by the provider, and the customer may be afforded substantial flexibility with respect to the networking configuration of the resources. The customer may, for example, select IP (Internet Protocol) addresses to the servers, define subnets of their choice, and so on. Such customer-configurable networks implemented using provider resources may be referred to by a variety of names, including “isolated virtual networks” or “virtual private clouds”. In some scenarios, customers may assign private IP addresses (i.e., addresses that are not visible or advertised outside the isolated virtual networks) to some resources within an isolated virtual network, e.g., without having to be concerned about the uniqueness of the addresses with respect to resources outside the isolated virtual network. The provider may support high levels of security, network isolation, and availability in such environments, enabling customers to run business-critical applications in the isolated virtual networks and experience a similar (or higher) quality of service to that achievable at customer-owned premises.
At least some providers that support isolated virtual networks may also implement a variety of other services, such as storage services, database services, and the like. Some of these other services may be designed to be accessible from the public Internet—e.g., a set of publicly-advertised IP addresses or corresponding URIs (uniform resource identifiers) may be set up for clients to access resources of such a service. At least in some environments, it may not be straightforward for customers that wish to access such publicly-advertised services from within their highly secure isolated virtual networks to do so without either potentially reducing security or incurring substantial costs.
While embodiments are described herein by way of example for several embodiments and illustrative drawings, those skilled in the art will recognize that embodiments are not limited to the embodiments or drawings described. It should be understood, that the drawings and detailed description thereto are not intended to limit embodiments to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope as defined by the appended claims. The headings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description or the claims. As used throughout this application, the word “may” is used in a permissive sense (i.e., meaning having the potential to), rather than the mandatory sense (i.e., meaning must). Similarly, the words “include,” “including,” and “includes” mean including, but not limited to.